METHODS FOR MANAGING BANDWIDTH 
IN A PACKET-BASED COMMUNICATION SYSTEM 
INCORPORATING A RESERVATION PROXY FUNCTION 



5 CROSS-REFERENCE TO RELATED APPLICATIONS 

This invention is related to U.S. Patent Application Serial No. 09/728,621, 
titled "Method for Managing Bandwidth in a Packet-Based Communication 
System" and Serial No. 09/728,620, titled "Method for Managing Bandwidth in a 
Packet-Based Communication System Using Call Unit Reservations," both filed 
10 December 1 , 2000, assigned to the assignee of the present invention and 
incorporated herein by reference in their entirety. 

FIELD OF THE INVENTION 

This invention generally relates to packet-based communication systems 
15 and, in particular, to a method of managing bandwidth in a packet-based 
communication system using a reservation proxy function. 

BACKGROUND OF THE 0>fVENTION 

Communication systems typically include a plurality of communication 
20 units, such as mobile or portable radio units, dispatch consoles and base stations 
(sometimes called base site repeaters) that are geographically distributed among 
various base sites and console sites. The radio units wirelessly communicate with 
the base stations and each other using radio frequency (RF) communication 
resources, and are often logica][ly divided into various subgroups or talkgroups. 
25 Communication systems are often organized as trunked systems, where the 

RF communication resources aire allocated on a call-by-call basis among multiple 
users or groups. Wide-area trunked systems are sometimes organized into a 
plurality of "zones," wherein each zone includes multiple sites and a central 
controller or server ("zone controller") for allocating communication resources 
30 among the multiple sites. The zone controller(s) may reside within a single device 
or multiple devices and may be located at a fixed equipment site or may be 
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distributed among various base sites. The RF resources may comprise, for 
example, narrow band frequency modulated channels, time division modulated 
slots, carrier frequencies, frequency pairs, or generally any medium for 
communicating information, such as voice, video, or data traffic ("payload 
5 information") or control signaling ("control information") to and from 
participating communication devices over wireless link(s). 

Traditionally, the base sites and console sites were linked via a circuit- 
switched architecture, through dedicated or on-demand circuits to a central radio 
system switching point ("central switch"). The circuits providing connectivity to 

] 0 the central switch required a dedicated wire for each endpoint (e.g., base site or 
console site) whether or not the endpoint was participating in a particular call. 

More recently, communication systems are begiiming to use packet- 
switched technology where information that is to be communicated between 
endpoints is divided into packets and transported by various routers forming an 

15 Internet Protocol (IP) network.. Packet-switched networks, sometimes called 
"connectionless" networks, aie considered to be more efficient than circuit- 
switched networks because they allow for dynamic bandwidth allocation to 
participating devices on an as needed basis. 

Due to the "connectioiriless" nature of packet-based networks, it is possible 

20 to over-subscribe certain links including, but not limited to, inter-zone links that 
are leased by communication system customer(s). Generally, in any packet-based 
system, over-subscription of link(s) causes delays in transport of IP packets that 
adversely effect the quality of service of the network. Understandably, customers 
demand a certain quality of service and are more willing to occasionally queue (or 

25 "busy") inter-zone calls due to insufficient resources than to pay extra recurring 
costs to overprovision these links to accommodate peak traffic loads. The 
problem is exacerbated in very large systems that may include hundreds of zones 
and hundreds of inter-zone links. Accordingly, there is a need for a method of call 
control in a packet-based communication system that provides for establishing 

30 calls over shared links of an IP network without exceeding available bandwidth. 
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One manner of addressing these needs is described in related patent 
application 09/728,620, wherein reservations of bandwidth are statically 
established (i.e., pre-determined) for certain links by a first host device (e.g., zone 
controller) on behalf of at least a second host device (e.g., base station) that may 
5 require use of bandwidth. The; reservations of call units are established using 
standard ReSerVation Setup Protocol (RSVP) signaling, prior to receiving any 
call requests, using multicast group address(es) that are never used for actual calls. 
If the zone controller receives a call request, it grants the request if there are 
sufficient reserved call units to support the call, in which case it forwards a 
10 different multicast address (i.e., different from the address(es) used to make the 
reservations) to participating endpoints and the call may proceed using that 
multicast address. 

The present application provides an alternative maimer of addressing the 
stated needs, whereby reservations of bandwidth for certain links are established 

1 5 dynamically (on a call-by-call basis) by host device(s) incorporating a reservation 
proxy function. The method provides for the host devices (hereinafter 
"reservation proxy elements") to obtain reservations of call units using RSVP 
signaling using multicast group address(es) that are used for actual calls. 
Advantageously, the method naay provide for limiting the scope of RSVP 

20 signaling to inter-zone links to minimize signal delays and the consxrmption of site 
bandwidth. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other advantages of the invention will become apparent 
25 upon reading the following detailed description and upon reference to the 
drawings in which: 

FIG. 1 shows a multi-zone packet-based communication system 
incorporating reservation proxy elements according to one embodiment of the 
invention; 
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FIG. 2 is a block diagram useM for illustrating an RS VP message 
sequence between reservation proxy elements and routers of a multi-zone packet- 
based communication system; 

FIG. 3 is a flowchart showing steps performed by reservation proxy 
5 element(s) to set up a prospective multicast call according to one embodiment of 
the invention; and 

FIG. 4 is a flowchart showing steps performed by a zone controller to 
implement a multicast call according to one embodiment of the invention. 

1 0 DESCRIPTION OF PREIFERRED EMBODIMENTS 

FIG. 1 shows by way of example and not limitation, a packet-based 
cormnimication system 100 comprising a plurality of base sites 102 organized into 
a plurality of zones ("Zone 1" through "Zone 4"). For convenience, the base sites 
102 are shown only at Zone 1, although it will be understood that base sites are 

1 5 also at Zones 2, 3 and 4. The base sites 1 02 include base stations 1 06 for 
communicating via RF resources with wireless communication units (e.g., 
communication units 156-163) within their respective coverage areas, which 
communication units may roam from site to site and from zone to zone. 

The base sites 102 are logically coupled, via router elements 104 ("base 

20 site routers") to router elements 1 1 6, 1 1 8, 1 20, 1 22 ("core routers") associated 
with their respective zones. The core routers are logically connected via packet 
network (inter-zone) links 148, 150, 152, 154. The core routers 116, 118, 120, 
122 are connected to respective zone controllers 124, 126, 128, 130 that perform 
call processing and mobility management functions for communication units 

25 within their respective zones. 

The base site routers 1 04 and the core routers 1 16, 1 18, 120, 122 are 
functional elements that may be embodied in separate physical devices or 
combinations of such devices, which devices comprise specialized or general 
purpose computing devices configured to receive IP packets from a particular host 

30 in the communication system 1 00 and relay the packets to another router or 

CM04520H 4 Express Mail Label No. EL034003289US 



another host in the communication system 100. Packets may be distributed 
between zones using sparse mode routing protocols such as the Core Based Tree 
(CBT) protocol and the Protoc;ol Lidependent Multicast - Sparse Mode (PIM-SM) 
protocol, dense mode routing protocols such as the Distance Vector Multicast 
5 Routing Protocol (DVMRP), Protocol Independent Multicast - Dense Mode (PIM- 
DM) and the Multicast Open Shortest Path First (MOSPF) protocol, or virttially 
any other protocol suitable for transporting packets between hosts of the 
communication system 100. 

As will be appreciated, the communication system 1 00 may also include 

10 communication units such as consoles or infrastructure devices (not shown) 
including, for example, dispatch consoles, call loggers, site controller(s), 
comparator(s), telephone interconnect device(s), internet protocol telephony 
device(s), scanner(s) or gateway(s) for communicating with the communication 
units 156-163, base sites 102, base site routers 104, core routers 1 16, 1 18, 120, 

15 122, zone controllers 124, 126, 128, 130 or generally any communication device 
in the communication system 100. These devices are typically wireline devices, 
i.e., connected by wireline to the base site(s) or other infrastructure device(s) but 
may also be implemented as wireless devices. 

According to one aspect of the present invention, the communication 

20 system 100 includes a pluralitj/ of reservation proxy elements ("RPEs") 132, 134, 
136, 138 associated with the respective zones 1-4. The RPEs are functional 
elements that may be embodied in separate physical devices or combinations of 
such devices. In one embodiment, for example, the RPEs are incorporated within 
one or more of the zone controllers 124, 126, 128, 130. Alternatively, the RPEs 

25 may be incorporated within console(s), call logger(s) and/or other infrastructure 
device(s) that may be included within the communication system 100. In one 
embodiment, as will be described in greater detail in relation to FIG. 2 and FIG. 3, 
the RPEs use RSVP signaling to dynamically obtain reservations of bandwidth on 
one or more of the inter-zone links 148, 150, 152, 154 for a prospective call. 
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In one embodiment, the base stations 106, base site routers 104, core 
routers 116, 118, 120, 122, zone controllers 124, 126, 128, 130 andRPEs 132, 
134, 136, 138 of the communication system 100, as well as any consoles or 
wireline devices that may be included the communication system 100 comprise IP 
5 host devices that are able to send and receive IP packets or datagrams between 
other host devices of the network. Recent advances in technology have also 
extended IP host functionality to wireless communication units, in which case the 
wireless communication units 156-163 may comprise host devices as defined 
herein. Each host device has a unique IP address. The host devices include 

10 respective processors (which raay comprise, for example, microprocessors, 

microcontrollers, digital signal processors or combination of such devices) and 
memory (which may comprise, for example, volatile or non-volatile digital 
storage devices or combination of such devices). 

Turning now to FIG. 2, there is shown a simplified packet-based 

1 5 communication system 200 useful for showing an RSVP message sequence 
between RPEs (e.g., RPE 1, RPE 2, RPE 3) in multiple zones (e.g. Zones 1-3) 
connected by packet network inter-zone links (e.g., LI, L2, L3). In one 
embodiment of the present invention, an RSVP message sequence is used to 
dynamically obtain reservations of bandwidth on one or more inter-zone links 

20 (e.g., LI, L3), as will be described in greater detail in relation to FIG. 3. The 

RSVP protocol itself is described in detail in IETF RFC 2205, incorporated herein 
by reference. 

As shovm in FIG. 2, the RSVP message sequence is initiated by sourcing 
RPE 1 sending an RSVP "path" message202 its associated core router CRl. In 
25 one embodiment, the path message 202 is addressed to a multicast group address 
that is to be used for a prospective communication. The routers of the network 
forward the path message 202 to participating RPEs (e.g., RPE 2 and RPE 3) 
having joined the multicast address. Thus, in the present example, the path 
message 202 is routed across the link LI to core router CR2 and across link L3 to 
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core router CR3. In turn, CR2 and CR3 send the path message to RPE 2 and RPE 
3. 

Upon receiving the path messaged, RPE 2 and RPE 3 send RSVP 
"reserve" messages 204 back to RPE 1, which reserve messages essentially retrace 
5 the path as the path messages but in a reverse direction. Thus, in the present 

example, the reserve messages 204 are sent from RPE 2 to CR2 and from RPE 3 
to CR3, then from CR2 to CRl across the link LI and from CR3 to CRl across 
the link L3 and finally from CR I to RPE 1 . RPE 2 and RPE 3 receive 
confirmation from the network once the reservation is established. Thereafter, in 

10 one embodiment, the RPEs infoimi their associated zone controllers (not shown in 
FIG. 2) that bandwidth is available for a prospective call. Having been informed 
of resource availability, the zone controller(s) may set up the call between 
participating devices as will be described in FIG. 4. 

According to RSVP protocols, three types of reserve messages may be 

15 used: Wildcard Filter (WF), Shared Explicit (SE) or Fixed Filter (FF), each of 
which will result in a specific type of data flow behavior as follows: 

The WF style allows the same resource reservation to be shared by 
multiple senders. Valid senders are not specified in the reservation. In effect, the 
reservation provides a shared pipe, whose size is determined by the largest 

20 reservation in the session, independent of the number and identity of the senders. 
Thus, for example, a reservation of bandwidth on link LI using the WF style 
would allow for any sending host (e.g., site router SRI or SR2) to use the 
reservation without RPE 2 having specified SRI or SR2 in the reservation. 

The SE style is similar to WF, except the receiver is allowed to specify 

25 which hosts are to be included in the reservation. Thus, for example, SRI and 

SR2 might be specified as eligible senders by RPE 2 using the SE style of reserve 
message. The SE style assumes multiple hosts will not send simultaneously. 
Thus, in the present example, the SE style of reservation might reserve a single 
call unit of bandwidth on link L 1 which is eligible for use by either SRI or SR2, 

30 but not SRI and SR2 simultaneously. 
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The FF style creates distinct reservations for each sender in the session. 
Lidividual senders are specified in the reservation request message. Thus, for 
example, if SRI, SR2 are specified as eligible senders by RPE 2, , the FF style of 
reservation might reserve tv^o call units of bandwidth on link LI, i.e., one call unit 
of bandwidth for each of SRI, SR2, thereby allowing simultaneous use of link LI 
by both SRI and SR2. 

FIG. 3 shows steps performed by participating RPEs to set up a 
prospective multicast call according to one embodiment of the invention. In one 
embodiment, the participating RPEs are those RPEs associated with zones that 
will participate in the call. For example, with reference to FIG. 1, if the 
prospective call is to be a talkgroup call involving communication units 156-157 
(zone 2), 158-160 (zone 3) and ] 61-163 (zone 4), the participating RPEs comprise 
RPE 134 (zone 2), RPE 136 (zone 3) and RPE 138 (zone 4). 

At step 302, the participating RPEs (e.g., RPEs 134, 136, 138) receive a 
multicast group address associated with the call. In one embodiment, the 
multicast group address is communicated to the participating RPEs from a zone 
controller (e.g., zone controller 1 28) having received the call request and assigned 
the multicast group address for the prospective call, prior to granting the call 
request. 

At step 304, the participa.ting RPEs join the multicast group address, in 
one embodiment by sending IGMF Join messages to their attached core router. 
Thus, in the present example, RI'Es 134, 136, 138 send IGMP Join message to 
respective core routers 1 18, 120, 122. Upon joining the multicast group address, 
the participating RPEs are able to receive control messages (e.g., RSVP signaling 
messages) that are addressed to the multicast group address. 

After a predetermined settling time, each RPE sends at step 306 an RSVP 
path message or other suitable control message destined to the multicast group 
address received at step 306. Upon reception of a path message, each RPE sends 
at step 308 an RSVP reserve message that essentially retraces the path of the 
received path message. The reserve message may incorporate the Wildcard Filter, 
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Shared Explicit or Fixed Filter RSVP protocols, as described in relation to FIG. 2. 
In one embodiment, each reserve message requests confirmation from the network 
once the reservation is established. 

In the preferred embodiment, each participating RPE sends both path 
5 messages and reserve messages so as to establish two reservations on the affected 
inter-zone links — one in each direction. Thus, new reservations do not need to be 
established when the sourcing site changes from one zone to another during the 
call. 

At step 310, the RPE(s) determine an availability of communication 

10 resources (e.g., bandwidth) on the inter-zone links based on receiving (or not 
receiving) confirmation from the network that the appropriate reservation(s) are 
established for the prospective call. According to RSVP protocols, the receiving 
hosts (i.e., those sourcing RSVF' reserve messages) request confirmation from the 
network as to the RSVP reservation availability. In the preferred embodiment, 

1 5 each participating RPE acts as a receiving host, thus each participating RPE 

receives confirmation from the network as to the availability of bandwidth on its 
requested link reservation(s). Tke RPE(s) notify their local zone controller(s), 
which in turn notify the controlling zone controller of the availability (or non- • 
availability) of bandwidth for the prospective call at step 312. 

20 Optionally, at step 3 14, the RPEs determine whether to leave the multicast 

group. This is because the multicast group joined by the RPEs to receive control 
traffic to obtain a reservation of bandwidth for the prospective call is the same 
multicast group that will be used to receive payload (e.g., audio, video, etc.) once 
the prospective call is granted, thereby becoming an active call. RPEs may wish 

25 to leave the multicast group if they do not desire to receive payload for the active 
call. In the event any RPE desires to leave the multicast group address, it does so 
at step 316. 

At step 3 18, the RPEs determine whether the call is ended. Typically, this 
determination is made upon receiving a message from a zone controller so 
30 indicating that the call has ended!. If so, the RPEs tear down the RSVP 
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reservations at step 320 so as to free up bandwidth on the inter-zone links for 
subsequent calls. If the RPEs £ire still joined to the multicast group address when 
the call is ended, they leave the multicast group at step 322. 

FIG. 4 shows steps performed by a zone controller to set up a prospective 
multicast call according to one embodiment of the invention. In one embodiment, 
the zone controller is a "controlling zone controller" or "CZC" for the 
communication system. The CZC may be statically configured from among a 
plurality of zone controllers in the communication system. Alternatively, the CZC 
may be defined on a call by cal] basis. 

At step 402, the CZC receives a call request, for example, for a talkgroup 
call. The call request may be resceived, for example, from a wireless 
communication device , such as a mobile or portable radio, wireline 
communication device, console (wireless or wireline), base station, site confroller, 
comparator, telephone intercomiect device or internet protocol telephony device; 
or, in the case where the call request is sourced from a zone other than that of the 
CZC, the call request may be forwarded to the CZC from a zone controller 
associated with the sourcing zone. For example, with reference to FIG. 1, 
controller 128 (zone 3) may receive a call request from communication unit 158, 
via base site 102. If zone controller 128 is not the CZC, it forwards the call 
request to the CZC at step 402. 

Upon receiving the call request, the CZC determines at step 404 the 
locations of participating devices for the prospective call, and hence which zones 
(and RPEs) are required to participate in the prospective call. For example, with 
reference to FIG. 1, if the prospective call is to be a talkgroup call involving 
communication units 156-163, zones 2, 3, 4 and RPEs 134, 136, 138 are required 
to participate in the prospective call. 

At step 406, the CZC identifies a multicast group address for the 
prospective call. In one embodiment, the multicast group address comprises an 
address that is to be used for exchanging confrol messages (e.g., RSVP signaling) 
between participating RPEs during call set-up, as described in relation to FIG. 3, 
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and also to be used for communicating payload information between participating 
devices when the call is granted. In a preferred embodiment, the CZC identifies 
the multicast group address dynamically, on a call-by-call basis. Alternatively, 
static multicast group addresses associated with various talkgroup IDs may be 
5 stored in memory and then recalled upon receiving a call request, as appropriate. 

At step 408, the CZC sends the multicast group address to the participating 
RPEs, which in effect instructs the RPEs to join the multicast group address. In 
response, the RPEs join the multicast group address and attempt to obtain 
reservation of bandwidth to support the prospective call, as has been described in 

10 relation to FIG. 3. 

At step 410, the CZC sends a Resource Reservation Query to the RPEs. In 
one embodiment, this is accomplished by the CZC sending the query directly to 
the RPE in its own zone and indirectly to RPEs in other zones, the latter being 
accomplished by sending the query to the zone controllers in other participating 

1 5 zones, which zone controllers forward the query to the RPEs in their respective 
zones. 

At step 412, the CZC determines whether bandwidth is available to 
support the call, based on the responses of the RPEs to the Resource Reservation 
Query messages (as may be forwarded to the CZC from other participating zone 

20 controllers). If all participating zone controllers have responded and indicated the 
availability of the necessary resources, the CZC grants the call at step 416, by 
sending a call grant message to participating zone controllers. Otherwise, if the 
CZC determines that bandwidth is not available to support the call (based on the 
responses or lack of responses of the RPEs to the Resource Reservation Query 

25 messages), the CZC busies the call at step 414 until such time as resources 
become available to support the call. 

In one embodiment, the call grant messages issued by the CZC at step 416 
include the same multicast group address that is sent to the RPEs at step 408. 
Alternatively, the multicast group address may be passed to the participating zone 

30 controllers before issuing call grant messages. For example, the multicast group 
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address may be provided to the participating zone controllers at generally the 
same time as they are provided to the participating RPEs at step 408. 

In either case, at step 418, upon receiving the call grant message from the 
CZC, the participating zone controllers forward call grant messages including the 
5 multicast group address to participating devices in their respective zones. In 
effect, this instructs the participating devices to join the multicast group address 
so that they may receive payload for the active call. When the call ends (step 
420), the CZC instructs the participating devices for the call to leave the multicast 
group address at step 422. 

10 The present disclosure therefore identifies methods of call set-up and 

control in a packet-based conmiunication system that rely upon reservation proxy 
elements (RPEs) establishing reservations of bandwidth over inter-zone links, 
which reservations may be used by participating devices for active calls. 
Advantageously, the reservations are established on a call-by-call basis using 

1 5 RS VP signaling addressed to a multicast group address that is also used for the 
active calls. The RSVP signaling by RPEs, rather than participating endpoints, 
reduces call set-up time and improves scalability of the communication system. 
Further, by eliminating the requirement for participating endpoints to perform any 
RSVP signaling, the consvimption of precious site link bandwidth is reduced. 

20 The present invention may be embodied in other specific forms without 

departing from its spirit or essential characteristics. The described embodiments 
are to be considered in all respects only as illustrative and not restrictive. The 
scope of the invention is, therefore, indicated by the appended claims rather than 
by the foregoing description. All changes that come within the meaning and range 

25 of equivalency of the claims £Lre to be embraced within their scope. 
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